\chapter{Organizational Descriptor Model}
\label{ch:ODM}

The ODM includes
\begin{inparaenum}[\itshape i\upshape)]
    \item the \emph{potential organizational model} (see definition \ref{def:pom}) describing the list of goals, actors and all possible capabilities of each actor as well as all possible dependencies among actors;
    \item the \emph{evaluation model} in which users can specify which evaluators should be used in assessment. This model also contains the evaluators' configuration that might be used to control the evaluators' behavior at runtime. Users can add evaluators from a predefined list and their custom evaluators;
    \item the \emph{event simulation model} allows users to define a list of events being used during the event-based simulation which will be shown up in the next section.
\end{inparaenum}

\section{Potential Organizational Model}
The \emph{potential organizational model} maintains a list of goals, actors, dependency relationships that potentially generates organizational model. We formally define the potential organizational model as follows:

\begin{definition} \label{def:pom}
The potential organizational model $\mathcal{O}$ is a tuple of $\langle$ \Actors, \Goals, \Decompose, \Dependency, \Capabilities, \PropDescriptor, \PropValue$\rangle$, in which
\begin{itemize}
    \setlength{\parskip}{0cm}
    \item \Actors : is a set of actors,
    \item \Goals : is a set of goals,
    \item $\Decompose \subseteq \Set{AND, OR} \times \Goals \times 2^{\Goals} $: is a set of all possible decompositions for each goal in \Goals. A $\decompose = \Seq{[AND|OR], \goal, 2^{\Goals}} \in \Decompose$ is an AND/OR decomposition of goal \goal\ into other sub-goals. Goals are recursively decomposed until operations which can be assigned to human actors of software components.
    \item $\Dependency \subseteq \Actors \times \Actors \times \Goals$: is a set of dependency relationships between actors. A dependency relationship $\dependency = \Seq{\actor_1, \actor_2, \goal} \in \Dependency$ presents a potential delegation which actor $\actor_1$ can delegate the satisfaction of goal \goal\ to $\actor_2$.
    \item $\Capabilities \subseteq \Actors \times \Goals$ : is a set of actors' capabilities which describes goals provided by each actor.
    \item $\PropDescriptor$ : is a set of property descriptors. A property descriptor is triplet \Seq{name, d\_type, def\_value} which defines a property \emph{name} of type \emph{d\_type} with default value \emph{def\_value}. Each property descriptor is associated with an actor, goal or capability.
    \item $\PropValue: \Set{\Actors \cup \Goals \cup \Capabilities} \times \PropDescriptor \rightarrow value$: is a function mapping an actor, a goal, or a capability and a property descriptor to a scalar value. This value could be a \emph{text}, \emph{number}, or even reference to another object.
\end{itemize}
\end{definition}

\begin{figure}
    \centering
    \includegraphics[width=0.8\textwidth]{figures/diagram_pom}\\
    \caption{Potential organizational model class diagram}
    \label{fig:diagram_pom}
\end{figure}

The figure \ref{fig:diagram_pom} is the class diagram of the \emph{potential organizational model}. In this diagram, we focus on the relationship between entities; hence only important properties are displayed. The main entities in the diagram are \entityname{Actor} and \entityname{Goal} which represent actor and goal in the organizational model. The capability of each actor is captured in \entityname{Capability} showing which goals can be provided by this actor. In order to adapt with various domains, the properties of actor, goal and capability are constructed dynamically by inheriting these entities from a so-called \entityname{CustomizableObject}. Each \entityname{CustomizableObject} belongs to an \entityname{ObjectClass} which holds a list of \entityname{PropertyDescriptor}. Each \entityname{PropertyDescriptor} has name, data type and also the default value for a property. The \entityname{PropertyDescriptor} also specifies the PDDL function used to concert this property to the PDDL script. A \entityname{CustomizableObject} instance maintains its specific properties' value in a list of \entityname{PropertyValue}. For the ease of use of innocent users, all possible properties of actor, goal and capability are predefined by experts for specific application domain.

Beside, the \entityname{Decomposition} entity captures all possible decompositions of a goal. In the \emph{potential organizational model}, a goal is decomposed until it reaches to particular operations which can be performed by human actors or software components.

\section{Evaluation model}
The next part of the ODM is the \emph{evaluation model}. An evaluator is a tuple \Seq{name, executor, parameters}. The evaluator \emph{name} invokes the \emph{executor} with \emph{parameter} to carry out the assessment on a given solution.To this extend the evaluation model are defined as follows.
\begin{definition}
An evaluation mode is a tuple \Seq{\Evaluator, EP}
\begin{itemize}
    \setlength{\parskip}{0cm}
    \item \Evaluator: is a set of evaluators.
    \item $EP \subset \Set{\Actors \cup \Goals \cup \Capabilities} \times \PropDescriptor$: is a set of properties associated with actors, goals and capabilities. The properties are used by the evaluators to perform computation.
\end{itemize}
\end{definition}

The class diagram of the evaluator model is depicted in figure \ref{fig:diagram_em}. In this model, users are able to declare which evaluator will be used to do the quantitative evaluation. Each \entityname{Evaluator} contains the class name that implements the evaluator, and a list of options which will be passed to the implementation at runtime to configure its behavior. The implementation, certainly, has to implement a predefined interface called \entityname{IEvaluator}(see figure \ref{inf:IEvaluator}) in order to be understood by the system.  More discussion about quantitative evaluations and others is provided in section \ref{ch:Assessment}.

\begin{figure}
    \centering
    \includegraphics[width=0.8\textwidth]{figures/diagram_em}\\
    \caption{Evaluation model class diagram}
    \label{fig:diagram_em}
\end{figure}

\section{Event Model}
The final part of the ODM describes the event model which is used to carry out the event-based simulation. This part consists of list \entityname{EventSet} entities. Each \entityname{EventSet} has a name to distinguish itself with others; a Boolean property called \mono{Enabled} to let the simulator know whenever to use this event set; and a list of event definitions. The event definition employs the idea of \emph{Event Calculus} in which each event should be modeled as a triplet $\langle$\emph{precondition, post-condition, parameters}$\rangle$.

The \emph{event precondition} shows whenever the event should happen. It can be the absolute time while simulating a solution, a relative time correlated with other events i.e., after an action has been executed, or an event happens. Or it can the combination of primitive conditions.

On the other hand, the \emph{event post-conditio}n describes the effect of this event to the model. This effect is a list of reaction. There are many types of reaction, e.g., a reaction that modifies the ODM at runtime (more particularly, the potential organizational model part) by changing actors/goals properties, introducing new goals, actors as well as capabilities. Or another reaction refines the solution-generating process. The framework supports not only a list of built-in actions (listed in table \ref{tbl:reactions}), but also custom reactions. The custom reaction is a special reaction which allows users to embed their own actions into the framework without rebuilding the source code. %While defining custom reaction, users should specify the implementation class which should implement the interface \entityname{ICustomEventReaction} (see figure \ref{fig:ICustomEventReaction}), and a list of parameters used by the reaction at runtime.

The \emph{event parameters} are a list of values used by the reactions defined in the post-condition. These values are fed by user before the simulation. Or, they can be fed by the simulation engine base on the simulated environment at the moment events happen.

The event precondition and post-condition are depicted as \entityname{EventPrecondition} entity and \entityname{EventReaction} entity in the class diagram (see figure \ref{fig:diagram_eventmodel}).

\begin{figure}
    \centering
    \includegraphics[width=0.8\textwidth]{figures/diagram_eventmodel}\\
    \caption{Event model class diagram}
    \label{fig:diagram_eventmodel}
\end{figure}

As modeling event in this fashion, user is able to define many events with different effects by combining reactions (predefined and custom) in different order. In section \ref{sec:simulation-event}, we will discuss how events are used in our framework to carry out assessment. 